Applications, such as Apple's® “Wallet” (formerly referred to as “Passbook®”), allows users to store coupons, boarding passes, event tickets, store cards, credit cards, loyalty cards as well as debit cards. Such documents and cards may be stored on the user's computing device as an object in a .zip file containing various files, including a “manifest” file.
The manifest file may include a documentation for various data elements, such as a photo of the user, the age of the user, the address of the user and so forth along with a hash code, where a “hash code” refers to the value returned by performing a hash function on the actual/origin data element (e.g., age of 21 years of age). Such data elements may be sensitive data which the user desires to keep private. The manifest file is then digitally signed by a trusted authority to demonstrate the authenticity of the manifest file. Such a signature may be stored in a separate file, commonly referred to as the “signature file.”
When a “challenger,” such as a government agency, requests one or more data elements (e.g., age of user) from the user, the challenger then attempts to verify the integrity of the received data elements (e.g., age of the user) which may be provided in a manifest file as documentation of the data elements. The challenger may apply a public key of the trusted authority to the manifest file to validate that the manifest file is digitally signed by the trusted authority. The challenger may then read the manifest file to read the documentation of the data element in question (e.g., age of user) and verify the integrity of the data element using its associated hash code in the manifest file to the actual data provided of the data element.
However, the hash code associated with a particular data element (e.g., age of 21 years of age) is the same regardless of whether the documentation for that same data element is in the manifest file of user A or in the manifest file of user B. As a result, it would be possible to reverse engineer to identify the value of the data element (e.g., age of user is 21 years of age) for any user once it became known of the association of the hash code with the value of that data element. That is, by knowing that a particular hash code is associated with a value for a particular data element, then someone may determine if such sensitive data (e.g., age of user is 21 years of age) applies to a user by matching the known hash code for such sensitive information in the user's manifest file documentation of the data elements.
As a result, when a challenger desires to verify the integrity of a particular data element (e.g., age of the user), the challenger may be able to obtain other sensitive information (e.g., address of the user) that is not required to be verified by the challenger since the challenger receives the entire manifest file which contains documentation of all of the data elements.
Hence, there is a security issue in that a user's privacy information may be breached by allowing sensitive information to be exposed, including other sensitive data than what is necessarily to be verified by the challenger.